M1st1fy

Ayudándonos de las herramientas de desarrollador de nuestro navegador, podemos ver las peticiones que se están haciendo al servidor junto con las respuestas que éste nos provee.

Al recargar la página con las herramientas abiertas, vemos que para construir la página se realizan muchas peticiones diferentes. La primera de ellas, es el GET de la página per sé. Sin embargo, esta petición sólo devolvió la estructura general de la página pero no así las publicaciones de los usuarios.
Para obtener las publicaciones, el sistema realiza una segunda petición GET a /api/posts, que nos devuelve un JSON con la información.

Viendo un poco más en detalle los datos devueltos podemos obtener información sobre los demás usuarios de la plataforma.

Esto nos resulta útil para obtener el email de Juan Perez, a quien le tenemos que modificar el nombre.

Nuestro objetivo es poder acceder a la cuenta de Juan Perez para poder actualizar su nombre a Soy un idiota. Lamentablemente no conocemos su contraseña ni tenemos acceso a su casilla de email, pero podemos intentar atacar el mecanismo de modificación de claves para aún sin acceso a sus datos, tomar control de su perfil.

En primera aproximación habíamos descubierto que las URL de recupero de clave seguían el formato http://<dominio>/recovery?t=<token>. Si pudiéramos descubrir cómo está generando ese token el Back-End podríamos recuperar las cuentas de otros usuarios sin tener acceso a sus direcciones de email. Centrémonos entonces el descubrir qué hay detrás de ese misterioso token.

Teniendo una muestra de 1 es muy difícil lograr deducir con algún grado de certeza qué hay detrás del token, por ello, con la intención de entender qué hay detrás de ellos, lo primero que haremos será generar muchas solicitudes de recupero de clave a nuestra cuenta, así tendremos muchos tokens para jugar.

Obtuvimos los siguientes tokens:

Lo primero que notamos es que todos los tokens parecen ser 32 caracteres hexadecimales. Esto nos da una fuerte impresión de que el token podría ser realmente el hash de otra cosa.

Para confirmar esta teoría podemos utilizar una herramienta con capacidad para identificar posibles tipos de hash, como la provista por hashes.com o, si estamos en un entorno linux hash-identifier.
Para dar una explicación que sea útil sin importar el sistema operativo que el lector decida utilizar, en este documento utilizaremos la primera, pero pueden encontrar mucha información sobre la segunda en internet.

Ingresamos los tokens devueltos por el sistema en la página separados por un salto de línea y presionamos en SUBMIT & IDENTIFY.

Tal y como lo sospechábamos, la página nos indica que todos los tokens ingresados muy posiblemente sean un hash MD5.

Sabiendo esto, sólo nos faltaría saber qué es lo que están hasheando para obtener los token. Lo primero que se nos viene a la mente, es que el token sea en realidad el hash del EPOCH Time de cuando se solicitó la recuperación de clave.

Con la intención de verificar esta teoría, ayudándonos de la página EpochConverter, obtenemos los timestamp asociados a cada token generado.

Una vez asociados los tokens con su respectivo Epoch Time, podemos construir un script en Python que nos ayude a verificar nuestra teoría.

Sin embargo, tras probar con los diferentes hashes, no encontramos ninguna coincidencia.

Otra posibilidad es que el token sea en realidad el hash de un id en la base de datos, si modificamos el script anterior para probar números consecutivos a partir del 1.

Al ejecutarlo con el primer token recibido, obtenemos el siguiente resultado:

El script descubrió que el token es en realidad el hash MD5 del número 2424! Si repetimos la ejecución con los demás tokens veremos que todos los tokens son en realidad hashes de lo que parecerían ser números aledaños.